Basically, the persist var 100 is a kind of bottleneck in that it only allows one transaction to be in progress at a time, so its use needs to be serialized among different threads.  For our application, it is important not to block the supervisor for too long waiting to access PC comms, since it is responsible for managing a hardware watchdog and other time-sensitive stuff like handling Estop.

Actually, I have toyed with the idea of using all 8 persist vars (100-107) to make an 8-channel PC comms link, one for each thread, but that's probably overkill for now, and not compatible with KMotionCNC etc.  The idea is to pack more info in each persist var: 8 bit field for the command code, and 16-bit offset into gather buffer used for parameter passing and results.  Grabbing data from the gather buffer is faster than getting individual persist vars.